Towards Measurable Process Models

1 Motivation and Background Due to high market pressure, development of industrial software has to become cheaper, more exible, more reliable, and more eecient. Thus for all software development projects, improvement of the software development process has become an important objective. In order to be able to speak about and to reach improvement, two prerequisites have to be fulllled. First, explicit models of (parts of) the software process are needed, and second, metrics have to be deened to get concrete, comparable values about the quality of the software development process. The need for, and the beneets of, combining process models with metrics has been stated in several publications ((1, 2, 7, 9, 11]). In particular, successful experiences with the combination of the so-called Goal-Question-Metrics (G-Q-M) paradigm and process modelling are described in e.g. 10] and 4]. This position paper continues and exceeds substantially 4] by making their approach much more concrete. We here report about a combination of the G-Q-M paradigm with the SOCCA approach ((6]) to modelling of software processes. This has been applied to modelling, as part of a complete software process, the connguration management within a large software project at a product division of Philips in Eindhoven (NL). The achieved measurable SOCCA model has been analysed by the analysis and simulation tool HIT (Hierarchical Evaluation Tool) ((3, 5]), which was originally developed for performance evaluation of computing and communication systems. In chapter 2 we will explain our approach to reach measurable SOCCA models. Chapter 3 summarizes the setting and the results of an experiment executed at a Philips product division. The lessons learned as well as our position statements about the usage of measurable process models nish this paper. A more detailed description about the topics discussed here, can be found in 8]. 2 Measurable SOCCA Models Modelling a software process means to abstract from real-world situations and to identify the objects of (current) interest, their allowed behaviour as well as their allowed (coordinated) interactions. Objects of interest are, for instance, human as well as non-human process agents, process documents and process activities.